---
title:  How Transaction Events Are Managed
---

<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

Transactional cache operations are handled somewhat differently inside transactions than out.

#  During the Transaction

While the transaction is running, each transactional operation is passed to the cache writer local to the transactional view, if one is available. As with cache operations outside of transactions, the cache writer can abort the operation. Each operation the cache writer allows is applied to the transactional view in the cache and appended to the CacheEvent list in the TransactionEvent object.

## Event Conflation

The cache events are conflated, so if a key already has an event in the list, that event is removed and the current operation is added to the end of the list. So this series of calls inside a transaction:

``` pre
    Region.create (A, W);
    Region.put (A, valX);
    Region.put (B, valQ);
    Region.invalidate (A);
    Region.put (A, valY);
```

results in these events stored in the CacheEvent list:

``` pre
    put (B, valQ)
    put (A, valY)
```

# At commit and after commit

When the transaction is committed, Geode passes the `TransactionEvent` to the transaction writer local to the transactional view, if one is available. After commit, Geode :
    -   Passes the `TransactionEvent` to each installed transaction listener.
    -   Walks the `CacheEvent` list, calling all locally installed listeners for each operation listed.
    -   Distributes the `TransactionEvent` to all interested caches.
        **Note:**
        For Geode and global JTA transactions, the `EntryEvent` object contains the Geode transaction ID. JTA transaction events do not contain the JTA transaction ID.


